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This paper reports on initial experiments using J Moore’s Codewalker to reason about programs 
compiled to the Low-Level Virtual Machine (LLVM) intermediate form. Previously, we reported on 
a translator from LLVM to the applicative subset of Common Lisp accepted by the ACL2 theorem 
prover, producing executable ACL2 formal models, and allowing us to both prove theorems about 
the translated models as well as validate those models by testing. That translator provided many 
of the benefits of a pure decompilation into logic approach, but had the disadvantage of not being 
verified. The availability of Codewalker as of ACL2 7.0 has provided an opportunity to revisit this 
idea, and employ a more trustworthy decompilation into logic tool. Thus, we have employed the 
Codewalker method to create an interpreter for a subset of the LLVM instruction set, and have used 
Codewalker to analyze some simple array-based C programs compiled to LLVM form. We discuss 
advantages and limitations of the Codewalker-based method compared to the previous method, and 
provide some challenge problems for future Codewalker development. 


1 Introduction 

In previous work f9ll ifTTl . we built a translator from Low-Level Virtual Machine (LLVM) intermediate 
form lIT^ to the applicative subset of Common Lisp ITSl accepted by the ACL2 theorem prover ifT^ . 
and performed verification on the translated form using ACL2’s automated reasoning capabilities. 

LLVM is the intermediate form for many common compilers, including the clang compiler used 
by Apple OS X and iOS developers. LLVM supports a number of language frontends, and LLVM 
code generation targets exist for a wide variety of machines, including both CPUs and GPUs. LLVM 
is a register-based intermediate language in Static Single Assignment (SSA) form [4]. As such, LLVM 
supports any number of registers, each of which is only assigned once, statically (dynamically, of course, 
a given register can be assigned any number of times). Andrew Appel has observed that “SSA form is 
a kind of functional programming” ||T1 ; this observation, in turn, inspired us to build a translator from 
LLVM to the applicative subset of Common Lisp accepted by the ACL2 theorem prover. Our translator, 
written in OCaml ||3|, produced an executable ACL2 specification that was able to support proof-based 
verification, as well as validation via testing. 

The above approach was satisfactory for the technology that we had at hand for use with ACL2 
in 2013, but had the obvious weakness of relying on a fair amount of unverified code. The situation 
changed in late 2014, when J Moore released the initial version of Codewalker, an instruction-set-neutral 
decompilation-into-logic system, with ACL2 7.0 IfTSl . Thus, an experiment began in early 2015 to 
determine whether Codewalker could be used to produce a similar proof environment for LLVM code. 


M. Kaufmann and D. Rager (Eds.): ACL2 Workshop 2015 (ACL2 2015). 
EPTCS 192, 2015, pp. 79-[9l doi: 10.4204/EPTCS.192.7 
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unsigned long occurrences(unsigned long val, unsigned int n, 

unsigned long *array) { 
unsigned long num_occur = 0; 
unsigned int j = 0; 
for (j = 0; j < n; j++) { 

if (array[j] == val) num_occur++; 

} 

return num_occur; 


Figure 1: Example C code to count occurrences of an input value in an array. 


2 An Example 

As an example, consider the C source code of Figure [U This function counts the number of occurrences 
of a given value in the first n elements of an array. (NB: By default the clang compiler treats all int 
values as 32 bits wide, and all long values as 64 bits wide.) 

This is an admittedly simple example, but it allows us to narrate a complete analysis within the con¬ 
fines of this paper, and should be within Codewalker’s capabilities to analyze. We have also performed 
similar analyses for other small C programs, namely tail-recursive factorial, as well as a program to 
compute the sum of array elements. 

LLVM code for this function is produced by invoking clang as follows: clang -01 -S 
-emit-llvm occurrences. c. The generated LLVM code for clang version 6.1.0 (which supports 
LLVM 3.6.0) is excerpted in Figure|2l this is essentially the same code as reported in fOl- 

Observe that LLVM output is similar to assembly code, with labels and low-level opcodes like br 
(branch), icmp (integer compare) and load (load from memory). Registers are prepended with the 
character, and are given sometimes-meaningful names. Consistent with the SSA philosophy, no register 
appears on the left hand side of an assignment (“=”) more than once. A peculiar feature of LLVM code 
is the phi instruction, which provides register renaming at a branch target. 

2.1 Translation to ACL2 Syntax 

In previous work, we automatically translated the above LLVM program into an ACL2 functional pro¬ 
gram. In the current work, we merely translate the LLVM assembly code syntax into a form that is easier 
for ACL2 to process. The translated form for the LLVM code of Figure|2]is depicted in Figure |3] 

The instruction format is straightforward: if the LLVM instruction is a = ins b c, then the ACL2 
syntax is (INS A B O.Thus, (ADD x y z) stores the sum of the contents of registers (locals) y and z 
in register x; and (BR E F G) branches to the instruction word at the current program counter -i- offset F 
if register E is nonzero, and to the instruction word at the current program counter -i- offset G otherwise. 
A few new instructions have been added to aid in phi processing: (CONST X) pushes a constant value X 
on a LIFO stack; (PUSH Y) pushes the contents of register Y onto the stack; and (POPTO Z) pops the 
top of stack value into register Z. We also define a (HALT) instruction so we don’t have to worry about 
defining a refum linkage (fhis is fulure work). 

Each insfrucfion occupies one insfrucfion word (of indeterminate size), and each register holds an 
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define i64 ©occurrences(i64 7oVal, i32 7on, i64* 7oarray) { 

7ol = icmp eq i32 7on, 0 

br il 7ol, label 7o• _crit_edge, label 7o.lr.ph 
•Ir.ph: 

7oindvars.iv = phi i64 [ 7oindvars. iv.next, 7o-lr.ph ], [0, 7oO ] 
7onum_occur.01 = phi i64 [ 7o.nuin_occur.0, 7o.lr.ph ], [0, 7,0 ] 

7,2 = getelementptr inbounds i64* 7oarray, i64 7oindvars. iv 

703 = load i64* 7,2, align 8, !tbaa !1 

704 = icmp eq i64 7o3, 7oVal 

705 = zext il 7o4 to i64 

7o.num_occur.O = add i64 7o5, 7onum_occur.01 
7oindvars. iv. next = add nuw nsw i64 7oindvars. iv, 1 
7olftr .wideiv = trunc i64 7oindvars. iv.next to i32 
7oexitcond = icmp eq i32 7olftr.wideiv, 7on 
br il 7oexitcond, label 7o• _crit_edge, label 7o.Ir.ph 

._crit_edge: 

7onum_occur.0.Icssa = phi i64 [ 0, 7oO ] , [ 7o.num_occur.0, 7o.Ir.ph ] 
ret i64 7onum_occur. 0. Icssa 


Figure 2: LLVM code for the occurrences example. 
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reg[2] contains val 
reg[l] contains n 

reg[0] contains array base address 


(CONST 0) 

0 



(POPTO 3) 

1 

reg[3] <- 0 


(EQ 413) 

2 

n == 0? 


(CONST 0) 

3 



(POPTO 5) 

4 

phi(j), j <- 0 


(CONST 0) 

5 



(POPTO 6) 

6 

phi(num_occur), num_occur <- 0 

(BR 4 14 1) 

7 

branch to ._crit_edge 

if n == 0 

Ir.ph: 




(GETELPTR 705) 

8 

reg[7] <- mem address 

of arr[index] 

(LOAD 8 7) 

9 

reg[8] <- mem[reg[7]] 

= arr[index] 

(EQ 982) 

10 

reg[8] == val? 


(ADD 10 6 9) 

11 

num_occur conditional 

increment 

(CONST 1) 

12 



(POPTO 11) 

13 



(ADD 12 5 11) 

14 

reg[12] <- j+1 


(EQ 13 12 1) 

15 

j+1 == n? 


(PUSH 12) 

16 



(POPTO 5) 

17 

phi(j), j <- j+1 


(PUSH 10) 

18 



(POPTO 6) 

19 

phi(num_occur) 


(BR 13 1 -12) 

20 

loop back to .Ir.ph if 

j + 1 < n 


; ;._crit_edge: 

(PUSH 6) ; 21 push num_occur on stack 

(HALT) ; 22 


Figure 3: ACL2 representation of the LLVM eode for the oeeurrenees example. 
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unbounded integer. This represents a slight loss of fidelity relative to the previous work, but we thought 
it unwise to tackle issues related to both Codewalker and modular arithmetic at the same time. 


3 LL2: An LLVM Subset Interpreter 

Before being able to utilize Codewalker, we must first define an operafional semanfics, or inferprefer, 
for fhe fargef insfrucfion sef. The Codewalker sources provide one such example inferprefer, for fhe Ml 
subsef of fhe Java Virfual Machine (JVM) llT4l . We used fhis ACL2 code as fhe basis for our LLVM 
subsef inferprefer, called LL2. As is fypical wifh such an inferprefer wriffen in ACL2, a machine sfafe 
dafa sfrucfure is declared, and passed as a paramefer fo all funcfions fhaf read and/or wrife elemenfs 
of fhe sfafe. If a given funcfion updafes fhe sfafe, fhe modified sfafe musf be refumed. Obviously, 
for a large sfafe, funcfional updafe of fhe sfafe can become quife expensive. Thus, an ACL2 single- 
fhreaded objecf (sfobj) |21 is offen used fo represenf sfafe. The desfrucfive updafe properfy of sfobjs 
provides good performance when execufing funcfions on concrefe sfafe. The LL2 machine sfobj, called 
simply s, confains fields for fhe Program Counfer (PC), local variables, memory, slack, and program 
sforage. All bul fhe firsl can be Ihoughl of as lisls. Accessor and updater funcfions are dehned for 
all fields, wifh updalers preceded by a M’ characler; Ihus (loi k s) refrieves fhe klh local variable 
(or regisfer, in LLVM parlance), while (! loi j val s)) updafes fhe value of fhe jfh regisfer fo val. 
Note fhaf (loi k s) is defined as (nth k (rd :locals s)), and (!loi j val s) is defined as 
(wr :locals (update-nth j val (rd :locals s)) s). 

Once fhe machine slate dafa sfrucfure is defined, semanfic funcfions need fo be written for all sup¬ 
ported inslruclions. For example, fhe semanfic funcfion for (EQ x y z) is as follows: 

(defun execute-EQ (inst s) 

(declare (xargs :stobjs (s))) 

(let* ((s (!loi (argl inst) 

(if (= (loi (arg2 inst) s) (loi (arg3 inst) s)) 10) s)) 

(s (!pc (+ 1 (pc s)) s))) 
s)) 

where inst is fhe lisl form of an insfrucfion (as depicted in Figure O, (argl inst) is (nth 1 
inst), (arg2 inst) is (nth 2 inst), and (arg3 inst) is (nth 3 inst). Thus, execute-EQ 
sfores fhe value 1 in fhe register indicaled by fhe firsl argumenl if fhe value slored in fhe regisfer indicated 
by fhe second argumenl is equal fo fhe value slored in fhe regisfer indicaled by fhe fhird argumenl; fhe 
value 0 is slored in fhe firsl argumenl register olherwise. Finally, fhe program counfer is incremenled. 

Once semanfic funcfions have been written for every supporled insfrucfion, a simple insfrucfion se- 
leclor funcfion can be composed, as follows: 

(defun do-inst (inst s) 

(declare (xargs :stobjs (s))) 

(if (equal (op-code inst) ’ADD) 

(execute-ADD inst s) 

(if (equal (op-code inst) ’BR) 

(execute-BR inst s) 

(if (equal (op-code inst) ’CONST) 

(execute-CDNST inst s) 

... s)))...) 
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This instruction selector function is called by the instruction stepper function: 

(defun step (s) 

(declare (xargs :stobjs (s))) 

(let ((s (do-inst (next-inst s) s))) 
s)) 

where (next-inst s) is (nth (pc s) (program s)). 

Finally, the instruction stepper is called by the top-level LL2 interpeter: 

(defun 112 (s n) 

(declare (xargs :stobjs (s))) 

(if (zp n) 
s 

(let* ((s (step s))) 

(112 s (- n 1))))) 

Note that this is all fairly standard technique for defining an instruction set interpreter in ACL2; 
one peculiarity, however, is that the top-level interpreter argument order (namely, state followed by step 
count) is mandated by Codewalker. 

3.1 Concrete Execution 

It is advantageous to be able to validate LLVM programs by running them against concrete inputs. Since 
all of our interpreter functions are executable, we can readily perform such validation testing. In the 
ACL2 code of Figure IH we set up an initial state, establishing an array of length 8 starting at address 
100. We write various values into memory at increasing addresses. The array base address is stored in 
local 0, followed by the n and val parameters, in locals 1 and 2, respectively. The program is written 
using the (wr : program ’(...)) form. The program is stepped to conclusion by invoking (112 s 
113); the return value can be found at (loi 6 s). 

As we have written the value 399 into the array three times, when we run the interpreter and fetch the 
return result as described above, we obtain the expected value: 3. The interpreter executes approximately 
226,000 LLVM instructions per second on an ordinary laptop computer. This is approximately one-tenth 
the speed of our previous method, as is to be expected for an interpreted vs. compiled approach, but this 
performance level is still more than adequate for validation testing. 

4 Codewalker 

Now that the interpreter for LL2 is in place, we can begin to use Codewalker to perform decompilation 
into logic for LLVM programs, producing semantic functions for those programs that the ACL2 user can 
further reason about. The end goal is to prove that the LLVM code for a given function implements a 
much more abstract function, written in ACL2, about which we can readily prove interesting correctness 
properties. In the extensive code documentation for Codewalker, the system is described as follows ifT^ : 

Two main facilities are provided by Codewalker: the abstraction of a piece of code into an 
ACL2 “semantic function” that returns the same machine state, and the “projection” of such 
a function into another function that computes the final value of a given state component 
using only the values of the relevant initial state components. 
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(include-book "LL2") 
(in-package "LL2") 


loi 0 

o 

o 

1 

' s) 


loi 1 

8 s 

■ ) 


loi 2 

399 

' s) 


memi 

100 

399 

s) 

memi 

101 

234 

s) 

memi 

102 

0 s) 


memi 

103 

75 s 

0 

memi 

104 

399 

s) 

memi 

105 

399 

s) 

memi 

106 

(1- 

(expt 2 64) 

memi 

107 

20 s 

0 

pc 0 

s) 




(wr :program ’((CONST 0)...)) 


(112 s 113) ;; run to HALT 


Figure 4: Concrete test case for the occurrences example. 


Codewalker is independent of any particular machine model, as long as a step-based opera¬ 
tional semantics for the machine is defined in ACL2. To facilitate this language-independent 
analysis, the user must declare a “model API” that allows Codewalker to access functionality 
of the model (e.g., setting the pc in a symbolic state). Generally speaking. Codewalker ac¬ 
cesses the model by forming symbolic ACL2 expressions that answer certain questions, then 
applying the ACL2 simplifier with full access to user-proved lemmas, and then inspecting 
the resulting term to recover the answer. 

Thus, to begin, we tell Codewalker about our operational semantics using def-model-api, telling it 
the name of our interpreter function, the state variable, whether the state is a stobj, the name of the step 
function, and so on. We next introduce the program to be analyzed, and prove some simple theorems 
about it, e.g. that writes to state fields other than the program field don’t affect the program. 

Next, we provide Codewalker with important program-level invariants as well as loop invariants. We 
also assist the system by providing a measure for the loop clock function, as illustrated in Figure [H 

Finally, we set Codewalker to work, by invoking its def-semantics function. First, we ask Code¬ 
walker to generate a semantic function for the “preamble” of the code (before the loop), then ask it to 
produce a semantic function for the loop itself, as shown in Figure [6l We often wish to break up the 
processing in this way, and not give the entire function to Codewalker in a single chunk. One reason for 
this is that it can be tricky to craft just the right invariants that are true for preamble, as well as the loop 
and postlude, and that Codewalker will be able to process successfully. 

Codewalker development is still in its early phase, and the system is a bit “touchy” when it comes to 
the combination of focus regions, invariants, measure annotations, and so on that will result in success. 
In Codewalker’s defense, it is very sophisticated software attempting a very difficult job. To quote the 
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(defun hyps (s) 

(declare (xargs :stobjs (s))) 

(and (sp s) 

(natp (rd :pc s)) 

(< (rd :pc s) (len (rd :program s))) 
(< 16 (len (rd :locals s))) 
(integer-listp (rd :locals s)) 
(integer-listp (rd imemory s)) 
(integer-listp (rd :stack s)))) 

(defun-nx loop-pc-p (s) 

(= 8 (rd :pc s))) 

(defun-nx loop-inv (s) 

(< (nth 5 (rd :locals s)) 

(nth 1 (rd :locals s)))) 

(defun-nx program-inv (s) 

(and (natp (nth 0 (rd :locals s))) 

(natp (nth 1 (rd :locals s))) 
(integerp (nth 2 (rd :locals s))) 
(natp (nth 3 (rd :locals s))) 

(natp (nth 5 (rd :locals s))) 

(natp (nth 6 (rd :locals s))))) 

(defun-nx clk-8-measure (s) 

(nfix (if (not (loop-pc-p s)) 

(nth 1 (rd :locals s)) 

(- (nth 1 (rd :locals s)) 

(nth 5 (rd :locals s)))))) 


Figure 5: Some invariants and measures provided to Codewalker. 
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(def-semantics 
:init-pc 0 

:focus-regionp (lambda (pc) (and (<= 0 pc) (< pc 8))) 

:root-name preamble 

:hyps+ ((occurrences-programp s) 

(program-inv s))) 

(def-semantics 
:init-pc 8 

:focus-regionp (lambda (pc) (>= pc 8)) 

:root-name loop 

:hyps+ ((occurrences-programp s) 

(loop-inv s) (program-inv s) 

(<= (+ (nth 0 (rd :locals s)) (nth 1 (rd :locals s))) 

(len (rd :memory s)))) 

:annotations ((clk-loop-8 (declare (xargs :measure (clk-8-measure s)))) 

(sem-loop-8 (declare (xargs :measure (clk-8-measure s)))))) 


Figure 6: Invocations of Codewalker def-semantics for the occurrences example. 


Codewalker documentation: “Def-semantics actually prints a lot of stuff as it goes. It also often fails! 
Some of its error messages make supposedly helpful suggestions as to what’s ‘wrong.’ Often your 
response will be to prove more lemmas because things aren’t being reduced to the canonical forms. 
Another response might be to restrict the focus region or strengthen the invariant so as to avoid certain 
cases.” lITSl 

Codewalker produces decompilations of the indicated code segments, which we can then assemble 
using functional composition, e.g.: 

(defun-nx composition (s) 

(sem-loop-8 (sem-preamble-0 s))) 

Codewalker also produces correctness theorems about the generated semantics functions, e.g.: 

(DEFTHM SEM-PREAMBLE-O-CORRECT 
(IMPLIES (AND (HYPS S) 

(OCCURRENCES-PROGRAMP S) 

(PROGRAM-INV S) 

(EQUAL (RD :PC S) 0)) 

(EQUAL (LL2 S (CLK-PREAMBLE-0 S)) 

(SEM-PREAMBLE-0 S)))) 

(DEFTHM SEM-L00P-8-C0RRECT 
(IMPLIES (AND (HYPS S) 

(OCCURRENCES-PROGRAMP S) 

(LOOP-INV S) 

(PROGRAM-INV S) 
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(<= (+ (NTH 0 (RD :LOCALS S)) 

(NTH 1 (RD :LOCALS S))) 

(LEN (RD :MEMORY S))) 

(EQUAL (RD :PC S) 8)) 

(EQUAL (LL2 S (CLK-LOOP-8 S)) 

(SEM-LOOP-8 S)))) 

The latter theorem states that if the LL2 interpreter is poised at the top of the loop (pc = 8) then 
running the LL2 interpreter with the occurrences program loaded for a proper number of steps (given by 
(CLK-LOOP-8 S) yields the same result as executing the generated semantic function. 


5 Reasoning about LLVM Code via Codewalker Semantic Functions 

In order to reason about a function such as occurrences in ACL2, we first need to perform abstraction 
on the data types; particularly, we wish to abstract the input array to a Lisp list. Since we are utilizing 
stobjs, however, this abstraction has already been provided for us. (Recall that stobjs provide a list 
abstraction for array data types that feature an efficient, in-place, destructive implementation.) 

Next, we need a “golden” list-based specification of occurrences. This function should be easy to 
reason about using ACL2, and so should be written in non-tail-recursive style, as in the following: 

(defun occurlist (val 1st) 

(declare (xargs :guard (and (integerp val) (integer-listp 1st)))) 

(if (endp 1st) 

0 

(+ (if (= val (car 1st)) 1 0) 

(occurlist val (cdr 1st))))) 

We wish to prove that the execution of the LLVM instructions of the compiled occurrences func¬ 
tion operating over an array in memory produces a result equal to the occurlist function operating 
over a list. Unfortunately for the proof of the above, the semantic functions generated by Codewalker 
are tail-recursive. The proof actually proceeds by the use of two additional functions, a pair of tail- 
recursive/non-tail-recursive functions that are generated and proved equal by def iteration, a book 
found in centaur/misc in the standard ACL2 distribution. (This technique was earlier described 
in oa.) The call to def iteration is as follows: 

(acl2::defiteration occur-arr (num val s) 

(declare (xargs :stobjs s 

:guard (and (integerp num) (integerp val)))) 

(ifix (+ (if (= (nth ix (rd :memory s)) val) 1 0) num)) 

:returns num 
:index ix 

:last (len (rd :memory s))) 

We first prove that the value stored in the num_occur register (register 6) after execution of the 
composition of semantic functions generated by Codewalker is equal to the result of the tail-recursive 
function generated by the call to def iteration above: 
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(defthm composition-=-occur-arr-tailrec 
(implies 
(and (hyps s) 

(program-inv s) 

(occurrences-programp s) 

(<= (+ (nth 0 (rd :locals s)) (nth 1 (rd :locals s))) 

(len (rd rmemory s))) 

(= (nth 1 (rd :locals s)) (len (rd :memory s)))) 

(= (nth 6 (rd :locals (sem-loop-8 (sem-preamble-0 s)))) 

(occur-arr-tailrec 0 0 (nth 2 (rd :locals s)) s))) 

:hints (("Goal" :in-theory (enable occur-arr-tailrec) 

: cases ((= (len (rd :memory s)) 0) (> (len (rd :memory s)) 0))))) 

We then prove that the non-tail-recursive function generated by def iteration is equal to occurlist: 

(defthm occur-arr-iter-=-occurlist 
(implies 

(and (sp s) (integerp val) (integer-listp (rd :memory s)) 

(= (len (rd :memory s)) (len (rd :memory s)))) 

(= (occur-arr-iter (len (rd :memory s)) 0 val s) 

(occurlist val (rd :memory s))))) 

The above theorem can be proved by first proving the following lemma: 

(defthm occur-arr-iter-=-occurlist-take—thm 
(implies 
(and 

(sp s) (natp xx) (integerp val) 

(integer-listp (rd :memory s)) 

(<= XX (len (rd :memory s)))) 

(= (occur-arr-iter xx 0 val s) 

(occurlist val (take xx (rd :memory s))))) 

:hints (("Subgoal *1/1" :in-theory (enable occur-arr-iter)))) 

Since occur-arr-iter and occur-arr-tailrec are already proved equal by def iteration, the 
proof of composition-=-occurlist then follows readily. 

(defthm composition-=-occurlist 
(implies 
(and (hyps s) 

(program-inv s) 

(occurrences-programp s) 

(<= (+ (nth 0 (rd :locals s)) (nth 1 (rd :locals s))) 

(len (rd :memory s))) 

(= (nth 1 (rd :locals s)) (len (rd :memory s)))) 

(= (nth 6 (rd :locals (sem-loop-8 (sem-preamble-0 s)))) 

(occurlist (nth 2 (rd :locals s)) (rd :memory s))))) 

Finally, given the semantic function correctness theorems generated by Codewalker (namely, 
SEM-PREAMBLE-O-CORRECT and SEM-L00P-8-C0RRECT, the desired final theorem, depicted in Figure|7j 
can be stated and proved. 
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(defthm 112-running-occurrences-code-=-occurlist 
(implies 
(and (hyps s) 

(program-inv s) 

(occurrences-programp s) 

(<= (+ (nth 0 (rd :locals s)) (nth 1 (rd :locals s))) 

(len (rd :memory s))) 

(= (nth 1 (rd :locals s)) (len (rd :memory s))) 

(equal (rd :pc s) 0)) 

(= (nth 6 (rd :locals (112 (112 s (clk-preamble-0 s)) 

(clk-loop-8 (112 s (clk-preamble-0 s)))))) 
(occurlist (nth 2 (rd :locals s)) (rd :memory s)))) 

:hints (("Goal" :cases ((= (len (rd :memory s)) 0) 

(> (len (rd rmemory s)) 0))) 

("Subgoal 2" :in-theory (enable clk-loop-8)))) 


Figure 7: Final theorem, equating the result of executing the LLVM instructions for the occurrences 
program to its abstract “golden” specification. 


6 Related Work 


The technique of compiling to a Virtual Machine instruction set has made a significant comeback in the 
past twenty years, starting with the JVM, and continuing with Microsoft’s CIL, Android Dalvik, and 
LLVM. Our work on verification at the virtual machine instruction set level was inspired by J Moore’s 
pioneering work on JVM verification ifTTl . as well as Eric Smith’s more recent Axe system, which was 
used to verify a number of Java cryptographic programs at the bytecode level ll20l . 

Zhao et al. produced several different formalizations of operational semantics for LLVM in 
Coq l|2ll, noting that their intention is to produce a verified LLVM compiler, similar to the CompCert 
verified compiler due to Leroy flAl (CompCert does not utilize the LLVM intermediate form). The goal 
of Zhao et al. was not to produce a verification environment for LLVM bitcode, unlike the present work, 
but rather to prove the correctness of compiler passes that manipulate LLVM. Jules Villard at Imperial 
College London is developing llStar, a formal analysis tool for LLVM bitcode. Villard’s work so far has 
focused on proving properties of small LLVM programs that manipulate algebraic data types, utilizing 
the coreStar symbolic execution engine, separation logic, and SMT technology l[22ll . LLBMC fTI is 
a bounded model checker used in bug-finding for C programs that operates on LLVM bitcode. Simi- 
lary, KITTeL [6] performs termination analysis on C programs by examining LLVM bitcode. Finally, 
KLEE lO is a symbolic execution tool that operates on ELVM bitcode to produce coverage test cases 
and find bugs in C programs. 

Codewalker was directly influenced by Magnus Myreen’s “decompilation into logic” work |[T9l . 
It would be interesting to attempt to replicate the work done here using a combination of Myreen’s 
decompiler and Anthony Eox’s E3 instruction set description language lO. 
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7 Conclusion and Future Work 

We have used Codewalker, an instruction-set-neutral decompilation-into-logic system included with the 
ACL2 theorem prover, to formally analyze C programs that have been compiled to the LLVM interme¬ 
diate form. Work began by defining a stobj-based interpreter for a subset of the LLVM instruction set, 
guided by an existing interpreter for the Ml subset of the Java Virtual Machine. Several C programs, 
including programs to compute factorial, sum of array elements, and number of occurrences of a value 
in an array, were compiled to LLVM form, and hand-translated to an ACL2-friendly form that could be 
fed to the interpreter. Validation testing was then conducted on these programs using concrete inputs, 
before the programs were given to Codewalker for formal analysis. Program-wide invariants, as well as 
loop invariants and clock measure functions, were defined in order fo help Codewalker create semantic 
functions for program code segmenfs. The composition of fhese semantic functions was fhen proved 
equivalenf fo more absfracf funclions: firsl fo a fail-recursive form; fhen fo a non-fail-recursive form (fhe 
equably of fhe latter Iwo having previously been eslablished by fhe def iteration facilily); and finally 
fo a fop-level non-fail-recursive “golden” specificafion. Thus, we were able fo prove lhal several sample 
LLVM programs implemenl fhe fop-level specificalions for fhose programs. 

Fufure work will focus on using Codewalker fo analyze more complex C funclions, in particular 
funclions lhal fealure nesled loops, as well as funclions lhal employ runlime-allocaled memory. We 
have successfully processed fhe “straighl-line” segmenfs for an LLVM insertion sorl program (which 
fealures a nesled loop) using Codewalker, bul have nol yel successfully composed fhe generaled semantic 
funclions info a whole program for furlher analysis. Addifionally, now lhal basic programs operating on 
unbounded integers have been successfully analyzed using Codewalker, a new version of fhe LLVM 
inlerprefer should be developed lhal can supporl differenl finile data word sizes, as well as the LLVM 
call and ret instructions. Finally, we would like to apply Codewalker to additional instruction set 
architectures, focusing on physical ISAs, as opposed to virtual ISAs like LLVM. 
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